Method and apparatus for multi-domain authentication

ABSTRACT

A method and apparatus for multi-domain authentication is described. In one example, credentials are received for a user accessing a first domain. User access to the first domain and a second domain is confirmed. A token is created for access to the second domain and the is provided with access to the second domain.

CLAIM OF PRIORITY

This application claims priority to Provisional U.S. Patent App. No.61/441,957, filed on May 3, 2012, entitled “System and Method forMulti-Domain Authentication,” by Williams et al., which is incorporatedherein by reference in its entirety and for all purposes.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

FIELD OF THE INVENTION

The present disclosure relates generally to on-demand services providedover a data network such as the Internet, and more specifically to userauthentication across multiple domains.

BACKGROUND

The subject matter discussed in the background section should not beassumed to be prior art merely as a result of its mention in thebackground section. Similarly, a problem mentioned in the backgroundsection or associated with the subject matter of the background sectionshould not be assumed to have been previously recognized in the priorart. The subject matter in the background section merely representsdifferent approaches, which in and of themselves may also be inventions.

It is not uncommon for a website owner to change and update web domains.For example, after Jigsaw Data Corporation was acquired bysalesforce.com, inc., it was renamed data.com. As a result, users thatpreviously had accounts accessible on jigsaw.com, now have theiraccounts accessible through the data.com website. While redirecting fromone URL to another URL (or one domain to another domain) may be used,this does not completely preserve stringent authentication protocols,which are necessary to ensure security and trust.

In some cases, network service providers use different domains fordifferent services. However, authentication is not always maintainedthroughout all of the domains. For example, some network serviceproviders provide access to data using a first set of applications,access rights and a first user experience but provide a second domainthat provides different applications, access rights and user experiencefor the same data. As a result, a user may wish to access the data fromboth sites, depending on what the user intends to do with the data or onpreference.

BRIEF SUMMARY

A method and apparatus for multi-domain authentication is described. Inone example, credentials are received for a user accessing a firstdomain. User access to the first domain and a second domain isconfirmed. A token is created for access to the second domain and the isprovided with access to the second domain.

While one or more implementations and techniques are described withreference to an embodiment in which protecting against attacks fromoutside content is implemented in a system having an application serverproviding a front end for an on-demand database service capable ofsupporting multiple tenants, the one or more implementations andtechniques are not limited to multi-tenant databases nor deployment onapplication servers. Embodiments may be practiced using other databasearchitectures, i.e., ORACLE®, DB2® by IBM and the like without departingfrom the scope of the embodiments claimed.

Any of the above embodiments may be used alone or together with oneanother in any combination. The one or more implementations encompassedwithin this specification may also include embodiments that are onlypartially mentioned or alluded to or are not mentioned or alluded to atall in this brief summary or in the abstract. Although variousembodiments may have been motivated by various deficiencies with theprior art, which may be discussed or alluded to in one or more places inthe specification, the embodiments do not necessarily address any ofthese deficiencies. In other words, different embodiments may addressdifferent deficiencies that may be discussed in the specification. Someembodiments may only partially address some deficiencies or just onedeficiency that may be discussed in the specification, and someembodiments may not address any of these deficiencies.

BRIEF DESCRIPTION OF THE DRAWINGS

The included drawings are for illustrative purposes and serve only toprovide examples of possible structures and process steps for thedisclosed techniques for integrating on-demand applications and remotejobs. These drawings in no way limit any changes in form and detail thatmay be made to implementations by one skilled in the art withoutdeparting from the spirit and scope of the disclosure.

FIG. 1 is a simplified block level diagram of components and operationsfor multi-domain authentication in accordance with one implementation.

FIG. 2A is a process flow diagram of multi-domain authentication inaccordance with one implementation.

FIG. 2B is a process flow diagram of multi-domain authentication inaccordance with a second implementation.

FIG. 3 illustrates a representative system for multi-domainauthentication in accordance with one implementation;

FIG. 4 illustrates a block diagram of an example of an environmentwherein multi-domain authentication might be used; and

FIG. 5 illustrates a block diagram of an embodiment of elements of FIG.4 and various possible interconnections between these elements.

DETAILED DESCRIPTION General Overview

Applications of systems and methods according to one or moreimplementations are described in this section. These examples are beingprovided solely to add context and aid in the understanding of thepresent disclosure. It will thus be apparent to one skilled in the artthat the techniques described herein may be practiced without some orall of these specific details. In other instances, well known processsteps have not been described in detail in order to avoid unnecessarilyobscuring the present disclosure. Other applications are possible, suchthat the following examples should not be taken as definitive orlimiting either in scope or setting.

As used herein, the term “multi-tenant database system” refers to thosesystems in which various elements of hardware and software of thedatabase system may be shared by one or more customers. For example, agiven application server may simultaneously process requests for a greatnumber of customers, and a given database table may store rows for apotentially much greater number of customers.

The disclosed implementations provide for multi-domain authentication inan on-demand computing services environment. The authenticationprocedures may include computing tasks configured to be executed locallywithin the on-demand computing services environment or remotely atcomputing systems located outside at least a portion of the on-demandcomputing services environment.

FIG. 1 is a flow diagram of an implementation. As FIG. 1 illustrates,when a user logs into a first domain (“jigsaw.com,” “Classic Page,” or“Classic”), the user may be presented with a link that when clicked,causes creation of a Guid authentication token, which is inserted into adatabase (“DB”) and forwards the user to the second domain (“JDP”). Thesecond domain will access the database to obtain the Guid, and thenautomatically logs the user into the second domain. This authenticationprocess may be two-way, i.e., a user logging into the second domain mayalso access the first domain. In this fashion, during migration from afirst domain to a second domain, a user may be able to seamlessly accessdata through both domains without requiring additional authentication.

In particular as shown in FIG. 1, at 110 the user has logged in to afirst domain e.g. www.jigsaw.com. The user clicks on a redirection linkto be redirected to the second domain, e.g. www.jigsaw.data.com(referred to herein as Jdp). The user may have been using a webapplication on the first domain or any other features of the firstdomain or the user may be simply using the first page for login and theredirection link.

As a result, at 120 the Classic Page at www.jigsaw.com takes a re directaction. The redirect action includes creating a new GUID (GloballyUnique Identifier), for example a random or pseudo-random number andstoring the GUID in a database. The GUID is also forwarded to the Jdpdomain.

At 130 the Jdp domain then receives the redirect action as a requestobject from the Classic Page. It reads the GUID from the request objectand, for security, marks it as consumed. It also automatically logs theuser in to its own web application.

Process Description

In an implementation, use of a DB (database) may require creation of anew database or a new row in an existing database. Alternatively, anyother storage file system may be used, such as distributed key-valuestorage, relational database, and other storage systems. The DB mayrequire new fields in order to include the new token or authenticationinformation, e.g. (id, user_id, the key for the row; token_id, the GUIDor unique token for redirection; is_consumed, a yes or no to indicatewhether the token_id has been used; and create_ts, a time stamp toindicate when the token_id was created) for single sign-on (“SSO”). Inan implementation, when a token is generated, some unique informationmay need to be saved or created, e.g., a server-side IP address, inorder to prevent someone from hijacking or otherwise taking anotheruser's authentication credentials. In an implementation, theauthentication token is single-use only and consumed after each use,thereby increasing security and preventing unauthorized access to thesecond domain. In an implementation, the authentication token may onlybe valid for a configurable time period, e.g., 1 minute.

Other techniques may be used in order to maintain security. For example,with respect to the re-direction action, one or more of the followingmay be implemented:

a. HTTP Secure (https://) only (e.g., https:// . . . /SSORedirect.xhtml,a unique secure URL (Uniform Resource Locator) for single sign onredirection).

b. Check to ensure a user with sufficient privileges is in fact loggedin to the first domain (e.g., SQL (Structured Query Language) to verifya user has access or not: select * from user_has_role where user_id=<id>and role_id=5).

c. Check to see if the logged in user has an unconsumed and/or unexpiredtoken, and if so, use the token.

d. HTTP Secure re-direction to the second domain using a hash and/ortoken.

With respect to receiving the authentication token at the second domain,one or more of the following may be implemented:

a. HTTP Secure (e.g., https:// . . . /SSOReceive.xhtml?t= . . . &h= . .. where t=sso token and h=sha-256 hash of (uid+token), a unique secureURL to receive the single sign on redirections and hash a user ID withthe token or GUID).

b. At the second domain, also using HTTP Secure (e.g., https:// . . ./sso/receive?t= . . . &h= . . . where t=sso token and h=sha-256 hash of(uid+token).

c. Token and/or hash validation.

d. Make sure token is not consumed and expired (<1 minute old, db time).

e. If token is valid, then consume token, log in automatically (if notalready logged in), then in a non-limiting example where the firstdomain is classic and the second domain is jdp, setting“classic-jdp-sso”, true in http session.

With respect to logging a user out, one or more of the following may beimplemented:

a. Logout user from current site (first domain or second domain,depending upon where the user is currently active).

b. Make sure the flag (classic-jdp-sso) is clear before redirecting.

c. If “classic-jdp-sso” is set to “true”, then redirect to seconddomain's logout action.

d. JDP (second domain) will call https://<jigsaw classicsite>/Logout.xhtml (a secure URL at the first domain for logout).

e. Classic (first domain) will call https://<jdp web>/logout (a secureURL at the second domain for logout).

In the described examples, the first domain (Classic page) starts as auser landing domain. Login, access privileges, and secure data are allserved from this domain. A second domain (Jdp) may also be used as auser landing domain and serve login, access privileges, and secure data.Either domain may provide a redirect to the other domain. The differencebetween the two domains may be in the user experience, the applicationstructure, or in any other desired aspect of the two domains. In thejigsaw example, the first domain provides a “classic” or earlier userexperience and the second domain provides a new, updated userexperience. Both domains provide access to the same database. Howeverthe invention is not so limited. The two different domains may be usedto provide personalized experiences to particular user groups, toprovide more basic and more advance experiences, or to put differentfunctions and data in the forefront of the experience to suit differentuser needs.

Process Flow

The framework above can be described in the context of a process flow asshown in FIG. 2A. At 210, a user sends a page request to a first domain.This page request may be received by an application server, a servlet orany other aspect of a web server at the first domain. At 212, the userpresents credentials to the first domain. In some embodiments this isdone when the user logs in to a session at the first domain. This log incan be automated or manual. Instead of a login, any other method ofauthentication can be used. After logging in, the framework can employany of a variety of other processes to certify the authentication and toobtain privileges, rights, subscription status and any other informationand validation that may be desired. In addition, a session is startedbased on the login. This may involve sending session cookies,establishing and applying security settings, configuring a VPN (VirtualPrivate Network) or any other operations that may be desired.

At 214, the user requests redirection from the first domain to a seconddomain. This may be done for example, by clicking on a link, requestinga service not available on the first domain, presenting a particularunique request or in any of a variety of other ways. The redirectionrequest triggers a set of redirection actions by an application serveror other component of the first domain. While the present description ispresented in the context of a first domain and a second domain, theterms first and second are used only to identify one or the other of thetwo domains. The first domain is not first in any particularcharacteristic except that the described processes begin at the firstdomain.

At 216, the servlet at the first domain generates a session token. Thetoken may be in the form of a GUID, a single sign on token, or any othertype of identifier. The token may be a sequential number, a pseudorandomnumber or any of a variety of other types of tokens. Before generatingthe session token, the servlet may first check to make sure that theprimary session from 212 is valid. The primary session may be invalidbecause of an error in the login process or because of time elapsingsince authentication with the first domain. In that case, a validsession may have timed out. If there is no valid primary session thenthe user may be redirected to a log in screen or box to re-authenticatewith the first domain. Alternatively, as with the original login, thelogin may be performed in another way.

The session token is stored at 218 in a shared database, i.e. a databasethat can be accessed by the first and second domains. As mentioned abovethe first domain application server may optionally at 218 a generate anentire new row or in the shared database or provide new entries inexisting fields. Some of the fields that may be used together with thetoken in the shared database include an identification of the user, atimestamp for the token to time out, a server-side IP address, a flagfor whether the token is consumed, a session variable, and other fields.The user ID may be used not only to link the token to a particular userbut also to connect the token to other attributes of the user, such asaccess privileges, account status, and other attributes.

At 218, the token and the redirect URL to the second domain are sent tothe user. The user uses this information to send a page request to theredirect URL at 222. The token may be sent using a cookie that the userthen sends to the redirect URL in a page request or in response to arequest for the cookie from an application server at the second domain.

Having received the page request, the second domain is able to respondin a variety of different ways. In some embodiments, the second domainauthenticates the user to the second domain without any further actionfrom the user. The user is then provided with a seamless transition fromthe one domain to the other without compromising the security of eitherdomain. Before authenticating the user to the second domain using thereceived token, a variety of different optional checks may be performed.A variety of different or additional approaches may be applied dependingon the particular implementation. If any one or more of the checks causethe authentication at the second domain to fail, the application serverat the second domain may simply require the user to authenticateseparately for the second domain. As an alternative, the user may beredirected back to the first domain to first re-authenticate and theredirection to the second domain may be reattempted.

At 220 a, the second domain optionally checks to determine whether theuser's session with the first domain is valid. This may be done, forexample, by checking the shared database for a session cookie with thefirst domain. If a session cookie is found, then the authentication canbe continued. If there is no valid session cookie, then the frameworkmay reject the request or redirect the user back to the first domain tore-authenticate.

At 220 b, the second domain may optionally retrieve user permissions todetermine whether the user has sufficient privileges to access datausing the second domain. If the user's privileges are not sufficient forthe second domain, then the authentication may be denied. The retrieveduser privileges may also be used to control the user experience afterauthentication to the second domain.

At 220 c, the application server optionally checks to determine whetherthe provided token has already been consumed. For a single sign-ontoken, there may be a flag set in the shared database indicating whetherthe token has already been used to authenticate the user to the same oranother domain. In another embodiment, the token entry may be removedafter it has once been consumed indicating that it is no longeravailable for use. By limiting the use of the token, it cannot be usedby an attacker after it has already been used once by the user.

At 220 d, the application server optionally checks to determine whetherthe token has expired. This may be determined using a time stamp storedin the shared database or using a function included in the token or ahash value. If the token is being for a single redirect request, then itshould be consumed within a minute or two. A request that comes aftermore than a minute or two suggests that the request is suspicious.

Before or after one or more of the above checks the application at thesecond domain may process the receive token. At 224, the applicationserver compares the received token to the token stored in the shareddatabase. If there is not a match, then the automatic authentication isrejected. The user must either log in manually or re-authenticate to thefirst domain. If there is a match, then the user can be logged into thesecond domain without any direct action by the user. The user may thenbe provided with access to the second domain through the applicationserver to perform any actions supported by the second domain withoutseparately logging into the second domain.

To compare the token additional safeguards may optionally be taken. In asimple embodiment, the second domain receives the token from the userembedded in a cookie. The second domain servlet extracts the token andcompares it to the stored token for a direct match. In another example,the user receives the token from the first domain but then hashes itwith its user ID. This ID may be known to the user or sent to the userfrom the first or the second domain. The user then sends the hashedtoken an user ID to the second domain. The second domain takes the tokenand user ID from the shared database, hashes them and compare the resultto that received from the user. Alternatively, the token may be hashedwith other values or combined with other data, such as time stamps, orother authentication values.

As described above, the token may be hashed with a secure hashalgorithm, such as one of the SHA-2 cryptographic hash functions.sha-256 or any other hash or combination function may be used.

For additional security or data management, the second domain servletmay optionally perform additional functions after-authenticating theuser to the second domain. At 226 a, the token is optionally consumed.This prevents any other user, such as an attacker, from using the sametoken. At 226 b, a session variable for the session with the seconddomain may be set as true. Session cookies may be provided to the usertogether with any other desired session management functions andprocesses.

At 228, the user has finished the session and is ready to log out. Theuser sends a logout request to the second or first domain applicationserver. Upon receiving the logout request, the corresponding servletlogs the user out at the corresponding domain at 230. At 232 if thesession is still valid on the first domain, then the user may beredirected to the first domain. This allows the user to perform anydesired transactions at the other domain before logging out. Otherwisethe user remains logged out of both domains. Alternatively, the servletat the logged out domain may log the user out from the other domainwithout any direct user action. The sessions may also have a timeoutfeature that operates after some period of user inactivity. Typically,if the user selects redirection to the second domain, then the user willbecome inactive on the first domain and the session with the firstdomain will automatically time out. In such an embodiment, the user needonly log out of the second domain.

The framework above can alternatively be described in the context of aprocess flow as shown in FIG. 2B. According to this alternativepresentation at 260, user credential are received at a first domain. Thecredentials may be received in the form of a login request or any otherform. They may be received by any authentication component of oraccessible by the first domain.

At 262, a redirection request is received at the first domain. Theredirection request is for a redirection to a second domain. In theexample above, the first and second domain share access to a shareddatabase, however the invention is not so limited.

At 264, the requesting user is redirected to the second domain and at266 a token is generated for the redirected user. This token may begenerated by a servlet at the first domain, however, the invention isnot so limited. The token is sent to the user at 268 and it is stored ina location accessible to the second domain. Alternatively, the token maybe sent to the second domain.

At 270, the second domain receives the redirect request and receives thetoken. The token may be a part of the redirect request or sentseparately. The token is assessed at 272 to determine whether it canprovide authentication for the user. This may be done by comparing thetoken or a value derived from or using the token to the stored orseparately received token. The token, user identifications, and otherauthentication credentials may be encrypted using any of a variety ofdifferent encryption approaches. If the token is assessed to be reliableor trusted, then the user may be authenticated to the second domain.

More or fewer operations may be performed in the examples of FIGS. 2Aand 2B. The order of many of the operations may be changed and theentities or components described as performing one or more tasks may bechanged, depending on the particular implementation. While the methodsdescribed herein provide some security for authenticating the user tomultiple domains, additional security measures may be added to any oneor more of the operations.

System Description

FIG. 3 illustrates a simplified block diagram of a content deliverysystem. A customer, user, or client has a user terminal which may befixed or mobile, that supports a client terminal interface 301. In theillustrated example, the interface is a generic web browser, however, aspecialized application may be used instead of a web browser dependingon the particular implementation. Using the web browser or otherinterface, the user may upload and download content from a remotedatabase and from many different locations. The first client terminalinterface 301 has access to the cloud 303. Additional client browsers302, 304 also have access to the cloud. While three are shown, there maybe many thousands or more. The cloud 303 represents any number of director indirect, wired or wireless connections.

The client browser 301 is connected through the cloud 303 or through alocal area, metropolitan area, or wide area network to a plurality ofdifferent domains 306, 346, of which two are shown. The first domainincludes an application server 305. The application server servesapplications to the client browser through the cloud to provide accessto a tenant database 307. While in the present example, the tenantdatabase is a multi-tenant database, the database may be for a singletenant or for one or more entities within a greater structural umbrella.

Within the client browsers, in addition to a display 311, and a userinterface 313, there is a cookie storage area 315 and a login andauthentication module 317. The cookie storage works with theauthentication to track sessions and may also be used to storeauthentication credentials for the user.

The application server 305 of the first domain 306 includes applets andservlets 321 in addition to applications. A session authenticationservlet includes cookie storage 323 or access to cookie storage. Theapplication server also includes authentication and privileges 325coupled to the servlet to track credentials and privileges for each ofits users. The application server acts as an interface between theclient browser and the tenant databases 307.

A second application server 347 of a second domain 346 includes appletsand servlets 341 in addition to applications. The application serveralso includes authentication and privileges 345 coupled to the servletto track credentials and privileges for each of its users. Thisapplication server also acts as an interface between the client browserand the same tenant databases 307 as the application server of the firstdomain.

The tenant databases include a database 331 for shared data andadditional databases 335 for other domains, other tenants, and otherdata. This is shown as a single additional database, however, there maybe many databases to provide these additional components to the system.While the tenant database 207 is shown as being constructed frommultiple databases, there may be a single database with all of the dataseparated into multiple tables or domains.

In the illustrated example, the shared database contains client data 337which the client can access through the client browser 301. It alsocontains user token storage 339 for storing the temporary authenticationtokens described above. As described above, the client begins by seekinginformation from the first domain, but if redirected to the seconddomain, then client data is stored in the user token storage by thefirst domain. The second domain can then access this data in the shareddatabase and compare it to the data received from the client toauthenticate the client on the second domain. The data received from theclient may be in the form of a cookie received from the first domain.

FIG. 4 shows a block diagram of an environment 610 wherein an on-demanddatabase service might be used, in accordance with one implementation.

Environment 610 includes an on-demand database service 616. User system612 may be any machine or system that is used by a user to access adatabase user system. For example, any of user systems 612 can be ahandheld computing device, a mobile phone, a laptop computer, a workstation, and/or a network of computing devices. As illustrated in FIGS.4 and 5, user systems 612 might interact via a network 614 with theon-demand database service 616.

An on-demand database service, such as system 616, is a database systemthat is made available to outside users that do not need to necessarilybe concerned with building and/or maintaining the database system, butinstead may be available for their use when the users need the databasesystem (e.g., on the demand of the users). Some on-demand databaseservices may store information from one or more tenants stored intotables of a common database image to form a multi-tenant database system(MTS).

Accordingly, “on-demand database service 616” and “system 616” will beused interchangeably herein. A database image may include one or moredatabase objects. A relational database management system (RDBMS) or theequivalent may execute storage and retrieval of information against thedatabase object(s). Application platform 618 may be a framework thatallows the applications of system 616 to run, such as the hardwareand/or software, e.g., the operating system. In an implementation,on-demand database service 616 may include an application platform 618that enables creation, managing and executing one or more applicationsdeveloped by the provider of the on-demand database service, usersaccessing the on-demand database service via user systems 612, or thirdparty application developers accessing the on-demand database servicevia user systems 612.

One arrangement for elements of system 616 is shown in FIG. 4, includinga network interface 620, application platform 618, tenant data storage622 for tenant data 623, system data storage 624 for system data 625accessible to system 616 and possibly multiple tenants, program code 626for implementing various functions of system 616, and a process space628 for executing MTS system processes and tenant-specific processes,such as running applications as part of an application hosting service.Additional processes that may execute on system 616 include databaseindexing processes.

The users of user systems 612 may differ in their respective capacities,and the capacity of a particular user system 612 might be entirelydetermined by permissions (permission levels) for the current user. Forexample, where a call center agent is using a particular user system 612to interact with system 616, the user system 612 has the capacitiesallotted to that call center agent. However, while an administrator isusing that user system to interact with system 616, that user system hasthe capacities allotted to that administrator. In systems with ahierarchical role model, users at one permission level may have accessto applications, data, and database information accessible by a lowerpermission level user, but may not have access to certain applications,database information, and data accessible by a user at a higherpermission level. Thus, different users may have different capabilitieswith regard to accessing and modifying application and databaseinformation, depending on a user's security or permission level.

Network 614 is any network or combination of networks of devices thatcommunicate with one another. For example, network 614 can be any one orany combination of a LAN (local area network), WAN (wide area network),telephone network, wireless network, point-to-point network, starnetwork, token ring network, hub network, or other appropriateconfiguration. As the most common type of computer network in currentuse is a TCP/IP (Transfer Control Protocol and Internet Protocol)network (e.g., the Internet), that network will be used in many of theexamples herein. However, it should be understood that the networks usedin some implementations are not so limited, although TCP/IP is afrequently implemented protocol.

User systems 612 might communicate with system 616 using TCP/IP and, ata higher network level, use other common Internet protocols tocommunicate, such as HTTP, FTP, AFS, WAP, etc. In an example where HTTPis used, user system 612 might include an HTTP client commonly referredto as a “browser” for sending and receiving HTTP messages to and from anHTTP server at system 616. Such an HTTP server might be implemented asthe sole network interface between system 616 and network 614, but othertechniques might be used as well or instead. In some implementations,the interface between system 616 and network 614 includes load sharingfunctionality, such as round-robin HTTP request distributors to balanceloads and distribute incoming HTTP requests evenly over a plurality ofservers. At least as for the users that are accessing that server, eachof the plurality of servers has access to the MTS' data; however, otheralternative configurations may be used instead.

In one implementation, system 616, shown in FIG. 4, implements aweb-based customer relationship management (CRM) system. For example, inone implementation, system 616 includes application servers configuredto implement and execute CRM software applications as well as providerelated data, code, forms, web pages and other information to and fromuser systems 612 and to store to, and retrieve from, a database systemrelated data, objects, and Webpage content. With a multi-tenant system,data for multiple tenants may be stored in the same physical databaseobject, however, tenant data typically is arranged so that data of onetenant is kept logically separate from that of other tenants so that onetenant does not have access to another tenant's data, unless such datais expressly shared. In certain implementations, system 616 implementsapplications other than, or in addition to, a CRM application. Forexample, system 616 may provide tenant access to multiple hosted(standard and custom) applications. User (or third party developer)applications, which may or may not include CRM, may be supported by theapplication platform 618, which manages creation, storage of theapplications into one or more database objects and executing of theapplications in a virtual machine in the process space of the system616.

Each user system 612 could include a desktop personal computer,workstation, laptop, PDA, cell phone, or any wireless access protocol(WAP) enabled device or any other computing device capable ofinterfacing directly or indirectly to the Internet or other networkconnection. User system 612 typically runs an HTTP client, e.g., abrowsing program, such as Microsoft's Internet Explorer® browser,Mozilla's Firefox® browser, Opera's browser, or a WAP-enabled browser inthe case of a cell phone, PDA or other wireless device, or the like,allowing a user (e.g., subscriber of the multi-tenant database system)of user system 612 to access, process and view information, pages andapplications available to it from system 616 over network 614.

Each user system 612 also typically includes one or more user interfacedevices, such as a keyboard, a mouse, trackball, touch pad, touchscreen, pen or the like, for interacting with a graphical user interface(GUI) provided by the browser on a display (e.g., a monitor screen, LCDdisplay, etc.) in conjunction with pages, forms, applications and otherinformation provided by system 616 or other systems or servers. Forexample, the user interface device can be used to access data andapplications hosted by system 616, and to perform searches on storeddata, and otherwise allow a user to interact with various GUI pages thatmay be presented to a user. As discussed above, implementations aresuitable for use with the Internet, which refers to a specific globalinternetwork of networks. However, it should be understood that othernetworks can be used instead of the Internet, such as an intranet, anextranet, a virtual private network (VPN), a non-TCP/IP based network,any LAN or WAN or the like.

According to one implementation, each user system 612 and all of itscomponents are operator configurable using applications, such as abrowser, including computer code run using a central processing unitsuch as an Intel Pentium® processor or the like. Similarly, system 616(and additional instances of an MTS, where more than one is present) andall of their components might be operator configurable usingapplication(s) including computer code to run using a central processingunit such as processor system 617, which may include an Intel Pentium®processor or the like, and/or multiple processor units.

A computer program product implementation includes a machine-readablestorage medium (media) having instructions stored thereon/in which canbe used to program a computer to perform any of the processes of theimplementations described herein. Computer code for operating andconfiguring system 616 to intercommunicate and to process web pages,applications and other data and media content as described herein arepreferably downloaded and stored on a hard disk, but the entire programcode, or portions thereof, may also be stored in any other volatile ornon-volatile memory medium or device, such as a ROM or RAM, or providedon any media capable of storing program code, such as any type ofrotating media including floppy disks, optical discs, digital versatiledisk (DVD), compact disk (CD), microdrive, and magneto-optical disks,and magnetic or optical cards, nanosystems (including molecular memoryICs), or any type of media or device suitable for storing instructionsand/or data. Additionally, the entire program code, or portions thereof,may be transmitted and downloaded from a software source over atransmission medium, e.g., over the Internet, or from another server, ortransmitted over any other conventional network connection (e.g.,extranet, VPN, LAN, etc.) using any communication medium and protocols(e.g., TCP/IP, HTTP, HTTPS, Ethernet, etc.). It will also be appreciatedthat computer code for implementing implementations can be implementedin any programming language that can be executed on a client systemand/or server or server system such as, for example, C, C++, HTML, anyother markup language, Java™ JavaScript®, ActiveX®, any other scriptinglanguage, such as VBScript, and many other programming languages as arewell known may be used. (Java™ is a trademark of Sun Microsystems®,Inc.).

According to one implementation, each system 616 is configured toprovide web pages, forms, applications, data and media content to user(client) systems 612 to support the access by user systems 612 astenants of system 616. As such, system 616 provides security mechanismsto keep each tenant's data separate unless the data is shared. If morethan one MTS is used, they may be located in close proximity to oneanother (e.g., in a server farm located in a single building or campus),or they may be distributed at locations remote from one another (e.g.,one or more servers located in city A and one or more servers located incity B). As used herein, each MTS could include logically and/orphysically connected servers distributed locally or across one or moregeographic locations. Additionally, the term “server” is meant toinclude a computer system, including processing hardware and processspace(s), and an associated storage system and database application(e.g., OODBMS or RDBMS) as is well known in the art.

It should also be understood that “server system” and “server” are oftenused interchangeably herein. Similarly, the database object describedherein can be implemented as single databases, a distributed database, acollection of distributed databases, a database with redundant online oroffline backups or other redundancies, etc., and might include adistributed database or storage network and associated processingintelligence.

FIG. 5 also shows a block diagram of environment 610 furtherillustrating system 616 and various interconnections, in accordance withone implementation. FIG. 5 shows that user system 612 may includeprocessor system 612A, memory system 612B, input system 612C, and outputsystem 612D. FIG. 5 shows network 614 and system 616. FIG. 5 also showsthat system 616 may include tenant data storage 622, tenant data 623,system data storage 624, system data 625, User Interface (UI) 730,Application Program Interface (API) 732, PL/SOQL 734, save routines 736,application setup mechanism 738, applications servers 7001-700N, systemprocess space 702, tenant process spaces 704, tenant management processspace 710, tenant storage area 712, user storage 714, and applicationmetadata 716. In other implementations, environment 610 may not have thesame elements as those listed above and/or may have other elementsinstead of, or in addition to, those listed above.

User system 612, network 614, system 616, tenant data storage 622, andsystem data storage 624 were discussed above in FIG. 4. Regarding usersystem 612, processor system 612A may be any combination of processors.Memory system 612B may be any combination of one or more memory devices,short term, and/or long term memory. Input system 612C may be anycombination of input devices, such as keyboards, mice, trackballs,scanners, cameras, and/or interfaces to networks. Output system 612D maybe any combination of output devices, such as monitors, printers, and/orinterfaces to networks. As shown by FIG. 5, system 616 may include anetwork interface 620 (of FIG. 4) implemented as a set of HTTPapplication servers 700, an application platform 618, tenant datastorage 622, and system data storage 624. Also shown is system processspace 702, including individual tenant process spaces 704 and a tenantmanagement process space 710. Each application server 700 may beconfigured to tenant data storage 622 and the tenant data 623 therein,and system data storage 624 and the system data 625 therein to serverequests of user systems 612. The tenant data 623 might be divided intoindividual tenant storage areas 712, which can be either a physicalarrangement and/or a logical arrangement of data. Within each tenantstorage area 712, user storage 714 and application metadata 716 might besimilarly allocated for each user. For example, a copy of a user's mostrecently used (MRU) items might be stored to user storage 714.Similarly, a copy of MRU items for an entire organization that is atenant might be stored to tenant storage area 712. A UI 730 provides auser interface and an API 732 provides an application programmerinterface to system 616 resident processes to users and/or developers atuser systems 612. The tenant data and the system data may be stored invarious databases, such as Oracle™ databases.

Application platform 618 includes an application setup mechanism 738that supports application developers' creation and management ofapplications, which may be saved as metadata into tenant data storage622 by save routines 736 for execution by subscribers as tenant processspaces 704 managed by tenant management process 710 for example.Invocations to such applications may be coded using PL/SOQL 34 thatprovides a programming language style interface extension to API 732. Adetailed description of some PL/SOQL language implementations isdiscussed in commonly assigned U.S. Pat. No. 7,730,478, titled METHODAND SYSTEM FOR ALLOWING ACCESS TO DEVELOPED APPLICATIONS VIA AMULTI-TENANT ON-DEMAND DATABASE SERVICE, by Craig Weissman, filed Sep.21, 2007, which is hereby incorporated by reference in its entirety andfor all purposes. Invocations to applications may be detected by systemprocesses, which manage retrieving application metadata 716 for thesubscriber making the invocation and executing the metadata as anapplication in a virtual machine.

Each application server 700 may be communicably coupled to databasesystems, e.g., having access to system data 625 and tenant data 623, viaa different network connection. For example, one application server 7001 might be coupled via the network 614 (e.g., the Internet), anotherapplication server 700-N-1 might be coupled via a direct network link,and another application server 700 N might be coupled by yet a differentnetwork connection. Transfer Control Protocol and Internet Protocol(TCP/IP) are typical protocols for communicating between applicationservers 700 and the database system. However, other transport protocolsmay be used to optimize the system depending on the network interconnectused.

In certain implementations, each application server 700 is configured tohandle requests for any user associated with any organization that is atenant. Because it is desirable to be able to add and remove applicationservers from the server pool at any time for any reason, there ispreferably no server affinity for a user and/or organization to aspecific application server 700. In one implementation, therefore, aninterface system implementing a load balancing function (e.g., an F5Big-IP load balancer) is communicably coupled between the applicationservers 700 and the user systems 612 to distribute requests to theapplication servers 700. In one implementation, the load balancer uses aleast connections algorithm to route user requests to the applicationservers 700. Other examples of load balancing algorithms, such as roundrobin and observed response time, also can be used. For example, incertain implementations, three consecutive requests from the same usercould hit three different application servers 700, and three requestsfrom different users could hit the same application server 700. In thismanner, system 616 is multi-tenant, wherein system 616 handles storageof, and access to, different objects, data and applications acrossdisparate users and organizations.

As an example of storage, one tenant might be a company that employs asales force where each call center agent uses system 616 to manage theirsales process. Thus, a user might maintain contact data, leads data,customer follow-up data, performance data, goals and progress data,etc., all applicable to that user's personal sales process (e.g., intenant data storage 622). In an example of a MTS arrangement, since allof the data and the applications to access, view, modify, report,transmit, calculate, etc., can be maintained and accessed by a usersystem having nothing more than network access, the user can manage hisor her sales efforts and cycles from any of many different user systems.For example, if a call center agent is visiting a customer and thecustomer has Internet access in their lobby, the call center agent canobtain critical updates as to that customer while waiting for thecustomer to arrive in the lobby.

While each user's data might be separate from other users' dataregardless of the employers of each user, some data might beorganization-wide data shared or accessible by a plurality of users orall of the users for a given organization that is a tenant. Thus, theremight be some data structures managed by system 616 that are allocatedat the tenant level while other data structures might be managed at theuser level. Because an MTS might support multiple tenants includingpossible competitors, the MTS should have security protocols that keepdata, applications, and application use separate. Also, because manytenants may opt for access to an MTS rather than maintain their ownsystem, redundancy, up-time, and backup are additional functions thatmay be implemented in the MTS. In addition to user-specific data andtenant specific data, system 616 might also maintain system level datausable by multiple tenants or other data. Such system level data mightinclude industry reports, news, postings, and the like that are sharableamong tenants.

In certain implementations, user systems 612 (which may be clientmachines/systems) communicate with application servers 700 to requestand update system-level and tenant-level data from system 616 that mayrequire sending one or more queries to tenant data storage 622 and/orsystem data storage 624. System 616 (e.g., an application server 700 insystem 616) automatically generates one or more SQL statements (e.g.,SQL queries) that are designed to access the desired information. Systemdata storage 624 may generate query plans to access the requested datafrom the database.

Each database can generally be viewed as a collection of objects, suchas a set of logical tables, containing data fitted into predefinedcategories. A “table” is one representation of a data object, and may beused herein to simplify the conceptual description of objects and customobjects according to some implementations. It should be understood that“table” and “object” may be used interchangeably herein. Each tablegenerally contains one or more data categories logically arranged ascolumns or fields in a viewable schema. Each row or record of a tablecontains an instance of data for each category defined by the fields.For example, a CRM database may include a table that describes acustomer with fields for basic contact information such as name,address, phone number, fax number, etc. Another table might describe apurchase order, including fields for information such as customer,product, sale price, date, etc. In some multi-tenant database systems,standard entity tables might be provided for use by all tenants. For CRMdatabase applications, such standard entities might include tables foraccount, contact, lead, and opportunity data, each containingpre-defined fields. It should be understood that the word “entity” mayalso be used interchangeably herein with “object” and “table”.

In some multi-tenant database systems, tenants may be allowed to createand store custom objects, or they may be allowed to customize standardentities or objects, for example by creating custom fields for standardobjects, including custom index fields. U.S. Pat. No. 7,779,039, titledCUSTOM ENTITIES AND FIELDS IN A MULTI-TENANT DATABASE SYSTEM, byWeissman, et al., and which is hereby incorporated by reference in itsentirety and for all purposes, teaches systems and methods for creatingcustom objects as well as customizing standard objects in a multi-tenantdatabase system. In some implementations, for example, all custom entitydata rows are stored in a single multi-tenant physical table, which maycontain multiple logical tables per organization. In someimplementations, multiple “tables” for a single customer may actually bestored in one large table and/or in the same table as the data of othercustomers.

These and other aspects of the disclosure may be implemented by varioustypes of hardware, software, firmware, etc. For example, some featuresof the disclosure may be implemented, at least in part, bymachine-readable media that include program instructions, stateinformation, etc., for performing various operations described herein.Examples of program instructions include both machine code, such asproduced by a compiler, and files containing higher-level code that maybe executed by the computer using an interpreter. Examples ofmachine-readable media include, but are not limited to, magnetic mediasuch as hard disks, floppy disks, and magnetic tape; optical media suchas CD-ROM disks; magneto-optical media; and hardware devices that arespecially configured to store and perform program instructions, such asread-only memory devices (“ROM”) and random access memory (“RAM”).

While one or more implementations and techniques are described withreference to an implementation in which a service cloud console isimplemented in a system having an application server providing a frontend for an on-demand database service capable of supporting multipletenants, the one or more implementations and techniques are not limitedto multi-tenant databases nor deployment on application servers.Implementations may be practiced using other database architectures,i.e., ORACLE®, DB2® by IBM and the like without departing from the scopeof the implementations claimed.

Any of the above implementations may be used alone or together with oneanother in any combination. Although various implementations may havebeen motivated by various deficiencies with the prior art, which may bediscussed or alluded to in one or more places in the specification, theimplementations do not necessarily address any of these deficiencies. Inother words, different implementations may address differentdeficiencies that may be discussed in the specification. Someimplementations may only partially address some deficiencies or just onedeficiency that may be discussed in the specification, and someimplementations may not address any of these deficiencies.

While various implementations have been described herein, it should beunderstood that they have been presented by way of example only, and notlimitation. Thus, the breadth and scope of the present applicationshould not be limited by any of the implementations described herein,but should be defined only in accordance with the following andlater-submitted claims and their equivalents.

What is claimed is:
 1. A method comprising: receiving credentials for a user at a first domain receiving a request from the user at the first domain to redirect to a second domain; redirecting the user to the second domain; generating a token based on the user credentials on the first domain; sending the token to the user and storing the token; receiving a request from the user at the second domain, the request including the token; comparing the received token to the stored token and conditionally authenticating the user at the second domain based on the token comparison.
 2. The method of claim 1, wherein storing the token comprises storing the token in a database accessible to the first and the second domains.
 3. The method of claim 1, wherein receiving credentials comprises logging a user into a session on the first domain.
 4. The method of claim 1, wherein receiving a request comprises receiving a request to log the user into a session in the second domain and wherein authenticating the user comprises logging the user into a session on the first domain.
 5. The method of claim 1, wherein receiving the token comprises receiving a hash of the token with an ID of the user and wherein comparing comprises generating a hash of the stored token with a stored user ID and comparing the generated hash to the received hash.
 6. The method of claim 5, wherein sending the token to the user comprises sending the token not hashed with the user ID.
 7. The method of claim 1, further comprising searching for an active session for the user with the first domain and if no active session is found not authenticating the user at the second domain.
 8. The method of claim 7, wherein searching for an active session comprises searching for a valid session cookie.
 9. The method of claim 1, further comprising retrieving permissions of the user for the first domain and not authenticating the user at the second domain if the permissions are not sufficient for the first domain.
 10. The method of claim 9, wherein the first and second domains provide user access to a single shared database and wherein retrieving permissions comprises retrieving permissions for the user to access data in the single shared database and wherein sufficient permissions are permissions that allow the user to access data in the single shared database.
 11. The method of claim 1, further comprising checking to determine whether the token has been consumed and if the token has been consumed, then not authenticating the user at the second domain.
 12. The method of claim 11, further comprising consuming the token after authenticating the user at the second domain.
 13. The method of claim 1, further comprising checking to determine whether the token has expired and if the token has expired, then not authenticating the user at the second domain.
 14. A system comprising: a computing device having a memory to store instructions, and a processing device to execute the instructions, the computing device further having a mechanism to: receiving credentials for a user at a first domain receiving a request from the user at the first domain to redirect to a second domain; redirecting the user to the second domain; generating a token based on the user credentials on the first domain; sending the token to the user and storing the token; receiving a request from the user at the second domain, the request including the token; comparing the received token to the stored token and conditionally authenticating the user at the second domain based on the token comparison.
 15. The system of claim 14, further comprising a database shared by the first and second domain, the database including credentials for the user and wherein generating a user taken includes storing the token in the shared database.
 16. A computer-readable medium having instruction thereon that when operated on by a computer cause the computer to perform operations comprising: receiving credentials for a user at a first domain receiving a request from the user at the first domain to redirect to a second domain; redirecting the user to the second domain; generating a token based on the user credentials on the first domain; sending the token to the user and storing the token; receiving a request from the user at the second domain, the request including the token; comparing the received token to the stored token and conditionally authenticating the user at the second domain based on the token comparison.
 17. The medium of claim 16, the operations further comprising determining whether the user has a valid session with the first domain and wherein authenticating the user at the second domain comprises authenticating the user only if the user has a valid session with the first domain.
 18. A method comprising: receiving credentials for a user accessing a first domain; confirming that the user has access to the first domain and a second domain; creating a token for access to the second domain; and, providing the user access to the second domain.
 19. The method of claim 18, wherein receiving credentials comprises accessing a database shared by the first and the second domain to determine whether user credential for the first domain are stored in the shared database. 